The Error Library(errlib) provides a way for simplifying code by allowing the code writer to assume that everything has proceeded correctly. It also forces users of the code to either handle the error explicitly, or their code will abort. This means that there isn't any problem with people ignoring the return code from functions and therefore having their program behave strangely. Errlib allows errors from packages to be handled at different places in the code, separating out the exceptional case of an error occuring from the normal case. Errlib uses strings instead of integers for error codes, allowing libraries to evolve and have the compiler check to make sure there is consistancy between the library and the users of the library.
Errlib provides the abstraction of an error function which when called is guarenteed to never return. This allows you to write code that assumes that every operation prior to the current one successfully completed. For example, you can assume that all of the memory allocations proceeded correctly, or that the construction of a socket has proceeded correctly. Because errlib uses exceptions, it is still possible for the calling routines to handle errors that happen by performing an emergency save or something. Furthermore, rather than having a function which is called when an error occurs, which has be be saved and restored at appropriate times and can cause confusion by having the wrong function get called, exceptions allow a dynamic nesting of error handling functions. Furthermore, a routine can partially handle the problem and then pass the error farther back up the call stack to let some other routine handle the error.
Errlib makes information about the error currently being processed available in global variables. Errlib stores the current name of the program if it is set, so that error handling functions can print out what program is having the problem. Errlib also stores the name of the package, the error id, and the full error message as they were specified in the calls to the error functions.
Exceptions work by using setjmp and longjmp to create non-local flow control. The use of setjmp and longjmp are hidden inside of routines and macros, which lets exception use look more normal. The one case where you have to be careful is in the use of returns and gotos inside of error handling code. The exception macros wrap handling around the beginning and the end of the exception blocks, and if you return while inside those blocks, you will prevent the cleanup code from executing. This can cause corruption of the exception stack which will probably be detected when an exception is thrown. Mangling the exception stack will abort the program.
All use of the exception handling code begins with the WITH_HANDLING macro. Enclosed in the with_handling block should be code which could possibly raise an exception. at the end of that block is a HANDLE macro which begins the exception handling code. Inside of the handle block, the BEGIN_MATCH, XMATCH and END_MATCH macros can be used to determine what kind of exception occurred. For example:
char *math_packagever = "Exception Throwing Math V1.0";
char *math_Esqrtbad = "Sqrt(x<0) was called";
ErrorFunction matherf = LongJmpPrintErrorFunction;
double except_sqrt(double x)
{
if (x<0)
matherf(math_packagever,math_Esqrtbad,
"Tried to take the square root of %lf",x);
return sqrt(x);
}
void sqrt_test()
{
WITH_HANDLING {
except_sqrt(-1);
} HANDLE {
BEGIN_MATCH;
XMATCH(math,sqrtbad) {
fprintf(stderr,"Oops, invalid sqrt argument: %s,
exception_errmsg);
}
END_MATCH;
}
END_HANDLING;
}